Issues about Advance Reservation for Real-time Traffic

The Integrated Services Architecture (ISA) allows real-time multimedia applications to request the needed QoS to a congested network; but, if on one side the ISA gives to applications guarantees on the way their traffic will be handled, on the other side it does not guarantees if their QoS requests will be accepted. This could be a problem when planning a video conference, a long-distance phone call, a distributed computation or a telemedicine session: failure in the allocation of QoS leads to the failure of the communication itself, from the ISA point of view. In this paper we present issues implied by an Advance Reservation Architecture (ARA) which extends the traditional ISA to allow the applications to reserve resources in advance. The ARA provides for an advance reservation mechanism in the ISA architecture: a QoS request to the Admission Control module is accompanied with the start time and the end time of the effective reservation. The described solution distinguishes from other proposals because is designed taking into account the recently developed RSVP overhead reduction mechanisms. 1 THE INTEGRATED SERVICES ARCHITECURE The Internet we are presently working with is based on the TCP/IP stack of protocols. One of the characteristics of these protocols is that the routers switch packets as soon as possible, without making distinctions between IP packets; this simple and fast architecture has granted the Internet its world-wide success. This best-effort service has proved a good delivery mechanism for the traffic generated by mail, ftp and web applications that don’t need upper bound to the transmission time of an IP packets, nor need to use a constantly available bandwidth. This kind of service can’t be used for multimedia over the current, congested Internet: packet losses, high delays and jitters lead to the likely failure of a real-time communication. During the last years a lot of work [5, 13, 14, 15] has been devoted to the development of the Integrated Services Architecture (ISA) which defines new network services: using this architecture an application specifies to the Internet nodes (routers and hosts) its traffic’s QoS demand. Each node dedicates part of its resources (transmission rate, delay time and so on) to this kind of traffic and gives it a prioritized access to the resources, in a way sufficient to satisfy the QoS demands. The ISA was mainly designed to provide QoS to real-time unicast or multicast multimedia applications, but is likely to work as well with distributed computation or mission critical applications. 1.1 The RSVP protocol The RSVP protocol [6] plays a basic role in this architecture, because it conveys the application’s QoS requests to each node along the correct end-toend path. It was engineered to work tightly coupled with ISA services [9, 19], and though its usage is not mandatory in the ISA (i.e. someone can use other signalling protocols or can manually configure its routers), RSVP is the most widely used QoS signaling mechanism. On the other side, RSVP itself could be used as a general purpose signaling protocol. A QoS reservation request travels upstream (from the receiver towards the sender) inside an RSVP Resv message. When receiving a Resv message, each RSVP-capable node looks for the QoS parameters, and pass the reservation request to the Admission Control (AC) module. The AC is a basic module in the QoS architecture: it takes a local accept/reject decision whether the router has or has not sufficient resources to allocate the request. In order to manage well the separation between the ISA and the RSVP protocol, RSVP carries the QoS specifications in Flowspec ‘opaque’ objects. That is, RSVP carries them but is not interested about their meaning nor processing rules. Figure 1: Schema of a QoS host/router To grant Resv messages to traverse the exact end-toend reverse path through the network, an RSVP Path message is sent by the data sender before the Resv message; then, the Resv message follows hop-by-hop the correct reverse path traced by the Path message. Each of the Path and Resv message sets up a state in each traversed network’s node; this state is confirmed by periodically repeating the original Path/Resv message (typically each 30 seconds). 2 ADVANCE RESERVATION ARCHITECTURES An Advance Reservation Architecture (ARA) extends the traditional ISA to allow the applications to reserve resources in advance. In the ISA the reservation takes place immediately after the AC accepts the QoS request, so an application transmits the reservation request when it needs the reservation itself. An application can’t use any kind of QoS, if its request is rejected by the AC because other applications are using resources: it can only retransmit a new request asking for a smaller QoS or waiting for some time. An application could reserve QoS well in advance but in this way it is wasting network’s critical resources without using them (and perhaps paying for them). The way the AC is now performed impacts the whole ISA: if on one side the ISA gives to applications guarantees on the way their traffic will be handled, on the other side it does not guarantees if their QoS requests will be accepted. This could be a problem when planning a video conference, a long-distance phone call, a distributed computation, a telemedicine session: failure in the allocation of QoS leads to the failure of the communication itself, from the ISA point of view, and no mechanisms are provided to grant the access to the resources. An ARA provides for an advance reservation mechanism in the ISA architecture. A QoS request to the AC is accompanied with the estimated temporal bounds of the flow, i.e. the start time and the end time. That is, each application specifies both the flow’s QoS and the time when it foresees the request will be filed. When an advance reservation request arrives, an Advance Reservation Admission Control (ARAC) module looks up in an allocation table where all the requests are registered: if the requested resources are not fully available during all the specified time the request is rejected. Otherwise the request is accepted and the table is updated in order to accommodate the new request; the ARAC module does not update the classifier and the scheduler: the reservation will effectively start at the ‘start time’ contained in the request. What we obtain with the ARA is a simple architecture that applications can use to reserve resources in advance, to make sure that they can use them when needed: if an advance reservation request fails, another request for another period can be sent. Also, important advantages are reached by the network administrator’s point of view, i.e. the possibility to plan the allocation of resources, and to increase (if possible) the bandwidth dedicated to IS traffic just for the needed time, the possibility to schedule least urgent events at off-peak time, to monitor the future use of the network (who-useswhat-when). 3 ISA AND RSVP CHANGES IMPLIED BY THE ADVANCE RESERVATION ARCHITECTURE The RSVP protocol doesn’t need many changes in order to work with the ARA, and its functional specifications are thoroughly preserved. It is interesting to remark that the extensions implied by ARA do not impact the way how the RSVP protocol works, and this is a consequence of the clever work Data Admission Control RSVP process